Function Calling
LLMが外部ツールや関数を呼び出すための仕組み。LLMが自然言語の文脈から「この関数を呼ぶべき」と判断し、引数を生成する能力。
仕組み
- 開発者がツールの定義（名前、説明、引数スキーマ）をLLMに渡す
- LLMが会話の文脈からツールの呼び出しが必要と判断
- LLMがツール名と引数をJSON等の構造化形式で出力
- アプリケーション側でツールを実際に実行し、結果をLLMに返す
- LLMが実行結果を踏まえて応答を生成
LLM自体がツールを実行するのではなく、「何を呼ぶべきか」を判断するだけで、実際の実行はホスト側が担う。
ベンダーごとの呼称
| プロバイダー | 呼称 |
|---|---|
| OpenAI | Function Calling |
| Anthropic | Tool Use |
| Function Calling |
機能は本質的に同じだが、APIの仕様（スキーマ形式等）が異なるため、プロバイダーを切り替えるとコードの書き換えが必要になる。
MCPとの関係
Function Callingは「AIとツールの接続」という同じ目的を持つが、実装レベルで差異がある：
| 観点 | Function Calling | MCP |
|---|---|---|
| 標準化 | プロバイダー独自仕様 | オープンスタンダード |
| 再利用性 | 特定AIアプリ専用 | 複数AIアプリで共用可 |
| サーバー分離 | ホストアプリ内に統合 | 独立したMCPサーバー |
| 適用場面 | 単一アプリ、低レイテンシ重視 | 複数AI、ベンダー非依存 |
MCPは「AIのUSB-C」と例えられる。一度MCPサーバーを作れば、どのLLMからでも利用できる。
設計上の考慮点
- ツール定義の質: ツール名と説明の明瞭さが、LLMが正しく選択するかを左右する
- 引数スキーマ: 曖昧さのない型定義で誤った引数生成を防ぐ
- エラーハンドリング: ツール実行失敗時の挙動をLLMに伝える設計が必要
- セキュリティ: LLMが生成する引数は信頼できないユーザー入力として扱う